Modern web applications are typically written in both declarative and procedural code. In a typically application, the initial appearance of objects in the user interface can be defined using declarative code. However, in order to define how that interface changes over time—for example, how elements appear or are modified in response to user interaction—procedural code is generally used. In implementing such applications, the declarative and procedural parts may be defined using two different computer languages, such as Extensible Markup Language (XML), Hypertext Markup Language (HTML), Adobe Systems Incorporated's CFML™, and the like, for defining the declarative part, and such as Netscape Communications and Weblogs, Inc.'s JAVASCRIPT™, Sun Microsystems Inc.'s JAVA®, C++, and the like, for defining the procedural part.
Another technology allows for the declarative and procedural aspects to be defined by the same language. One language that provides for such a dual role is Adobe Systems Incorporated's MXML™. MXML™ an XML-based language, to describe Rich Internet Applications (RIAs), which are interactive, multimedia, applications, that may run on client-side players or within client-side process containers, for example, Adobe System Incorporated's FLASH® player. FLEX™ and FLEX BUILDER™, both available from Adobe Systems Incorporated's, utilize MXML™, an Extensible Markup Language (XML)-based language, to describe RIAs. FLEX™ is a presentation layer technology that, along with its application development environment (ADE), FLEX BUILDER™, are used to create RIAs. MXML™ is a tag-based markup language for describing applications. It is practically unique because while it is a declarative tag-based markup language, it not only describes the appearance of a particular web application, it can also describe the procedural logic as well. MXML™ compiles into ACTIONSCRIPT™, which is a procedural language from Adobe Systems Incorporated native to the FLASH® environment. Therefore, a direct relationship exists between the MXML™ markup and the ACTIONSCRIPT™ code.
The MXML™ markup defines both the initial appearance of the application (as in other declarative user interface languages) and the appearance of other states of the application that can be shown at different times (as in other procedural-type languages). For example, the application may initially show a list of products; when the user chooses a product, the list of products may shrink over to one side, and the selected product may be expanded to show more detail. In an ordinary application, the initial screen could be described declaratively, but the process of shrinking the list of products to one side and expanding the selected product would typically be described using procedural code. In MXML, both the initial screen and the “expanded product” screen can be defined as declarative states; the state syntax describes how the screen needs to change in order to go from one state to the next.
ADEs are software tools that allow a developer (e.g., a web developer, application developer, and the like) to create web pages, websites, interactive applications, and the like for use by end users (e.g., visitors to websites, application uses, and the like). Various ADEs exist in the current marketplace, such as DREAMWEAVER®, GOLIVE®, and FLEX BUILDER™ each available from Adobe Systems Incorporated of San Jose, Calif. DREAMWEAVER® and GOLIVE® are ADEs that allow web developers to design HTML web pages in both a code editor and a graphical-based design time environment. DREAMWEAVER® also allows the developer to design in other languages, such as, for example, ASP, CFML™, and the like. Much of a developer's job, whether creating a simple web page, a complex web application, or a RIA, is to create user interfaces (UIs) for the applications that are easy to use and enhance a user's experience.
When a developer is editing or creating a web application or RIA in an ADE, edits and changes to the application may either be directed to the initial appearance of the application or to a subsequent state. An ADE would typically have to interpret the underlying user interface code in order to present visual tools for manipulating the interface—for example, in a “What You See Is What You Get” (WYSIWYG) design view. When the states of an application are described procedurally, it is difficult for the ADE to interpret those states, and so developers can typically only edit the initial appearance of the application in the design view. Conversely, when the states of an application are described declaratively, as in MXML™, it is possible for the ADE to allow the developer to simulate and directly edit different states of the application in its design view. However, it can be difficult to do so efficiently, because a complex interpretation algorithm may be required to determine how an edit to the underlying declarative code affects the state currently being simulated in the design view. If the interpretation algorithm does not attempt to determine the minimal number of changes necessary to simulate the new appearance of the state based on the edit that occurred, the design view cannot be efficiently updated.